Sans répartition de charge, un seul serveur web absorbe l'intégralité du trafic. Si ce serveur tombe ou sature, le service est interrompu. L'objectif est de distribuer les requêtes entre deux serveurs, en envoyant deux fois plus de charge sur web1 que sur web2.

La section frontend écoute sur l'IP publique 172.30.206.206:80 et redirige vers le backend. La section backend utilise l'algorithme roundrobin avec pondération : weight 2 pour web1 et weight 1 pour web2. La commande option httpchk HEAD / HTTP/1.0 vérifie la disponibilité de chaque serveur avant d'envoyer du trafic.

• Modifier /etc/haproxy/haproxy.cfg — section frontend : bind 172.30.206.206:80 · default_backend mon_backend
• Section backend : balance roundrobin · server web1 172.20.206.81:80 weight 2 check · server web2 172.20.206.82:80 weight 1 check
• Différencier les pages HTML des deux serveurs (fond rouge pour web1, fond bleu pour web2)
• Tester depuis le navigateur : rechargements successifs → web1 apparaît 2x plus souvent que web2 ✅

Sans interface de supervision, il est impossible de vérifier en temps réel si la charge est bien répartie, de repérer un serveur saturé ou hors ligne, ou d'analyser le volume de trafic échangé par chaque backend.

Activation de la page de statistiques HAProxy via une section listen stats dans le fichier de configuration. La page est accessible sur le port 8404 à l'adresse 172.30.206.206:8404/stats, protégée par une authentification HTTP Basic (ablai:Sio2025). Un rafraîchissement automatique toutes les 10 secondes permet un monitoring en temps réel.

• Sessions actives — nombre de connexions en cours par frontend et backend
• Bytes In/Out — volume de trafic échangé par chaque serveur, pour vérifier la répartition
• Erreurs et avertissements — surcharge, configuration ou problème réseau détectés instantanément
• Statut détaillé — état UP/DOWN de chaque serveur backend, durée depuis le dernier check

Sans mécanisme de persistance de session, le load balancer envoie chaque nouvelle requête vers un serveur différent selon l'algorithme round-robin. Puisque chaque serveur gère ses propres sessions PHP indépendamment, un utilisateur peut se retrouver connecté avec un profil différent selon le backend qui répond à sa requête.

Deux fenêtres de navigateur pointant vers la même URL 172.30.206.206/siteFrais affichent des profils différents : « Cottin Vincenne » sur web1 et « Duduit Frédéric » sur web2. En rechargeant la page, l'identité change selon le serveur qui répond — comportement incohérent inacceptable en production.

• Aucun cookie de session partagé entre les serveurs
• Chaque backend attribue une session PHP indépendante à l'utilisateur
• L'utilisateur change « d'identité » à chaque changement de backend

Pour corriger les états incohérents du scénario 3, il faut garantir qu'un utilisateur reste connecté sur le même serveur backend pour toute la durée de sa session. Sans cette persistance, les applications nécessitant une authentification (comme l'intranet GSB) sont inutilisables en environnement load balancé.

Ajout de la directive cookie SRVNAME insert indirect nocache dans la section backend. HAProxy insère un cookie nommé SRVNAME dans la réponse HTTP avec la valeur web1 ou web2 selon le serveur choisi. Toutes les requêtes suivantes du même client sont ensuite systématiquement routées vers ce serveur.

• insert — HAProxy insère le cookie dans la réponse envoyée au client
• indirect — le cookie n'est pas transmis aux serveurs backends (transparent)
• nocache — empêche les proxies intermédiaires de mettre en cache les réponses contenant ce cookie
• Validation : le cookie SRVWEB=web1 apparaît dans les outils développeur du navigateur · session constante après rechargement ✅

Slowloris est une attaque de type Denial of Service (DoS) particulièrement efficace. Le script ouvre jusqu'à 1000 connexions HTTP simultanées vers la cible, en envoyant des requêtes partielles très lentement et en injectant périodiquement de faux en-têtes HTTP pour maintenir les connexions ouvertes. Le serveur sature ses ressources et ne peut plus répondre aux vraies requêtes. C'est une attaque silencieuse qui consomme peu de bande passante mais provoque un déni de service complet.

• Lancement de deux instances simultanées du script : ./slowloris.pl -dns 172.20.206.81
• Message confirmant l'attaque : « Connecting to 172.20.206.81:80 every 100 seconds with 1000 sockets »
• Commande de surveillance sur web1 : ss -anp | grep 80 | wc -l → résultats affichés : 805, 791, 790, 799… connexions simultanées
• Nombre de connexions anormalement élevé — serveur saturé, incapable de traiter les requêtes légitimes

• web1 : couleur rose · statut DOWN · sessions élevées · erreurs et refus visibles
• web2 : statut UP · sessions faibles · HAProxy bascule automatiquement tout le trafic vers web2
• Le load balancer absorbe l'attaque et maintient le service accessible via web2 — résilience prouvée